This invention relates to distributed object systems using common object request broker architecture (CORBA) and, more particularly, to a method and apparatus for implementing group object identification in object adapters.
Software programs are continually becoming more complicated. Early programs consisted of straightforward procedural code that presented a simple, command line interface and text display to the user. These simple programs have gradually been replaced with complex programs that have graphical user interfaces and multiple features.
As programs have grown in complexity, the amount of effort which is required to write and debug the programs has also increased drastically. Consequently, major efforts have been made to reduce the amount of programming necessary to produce a modern, full-featured product. One of the most successful of these efforts has been the development of object-oriented programming in which programs are designed as collections of discrete elements called xe2x80x9cobjectsxe2x80x9d. The objects can be modified and reused in many cases, thereby reducing the development effort.
As will be understood by those skilled in the art, objects in the context of object-oriented programming are software entities comprising data and methods or operations on that data. The methods of an object collectively form an interface for manipulating the data in the object. The objects exist only at program runtime and are created, or instantiated, from object xe2x80x9cclassesxe2x80x9d which are actually written by the programmer. The class code written by a programmer can be xe2x80x9creusedxe2x80x9d by another programmer by instantiating objects from that code.
In order to further reduce the programming burden, distributed object systems have been developed in which methods in objects resident on a server can be executed or invoked remotely over a network from a client application. In this manner, the objects can be developed and maintained by a party different from the party that developed the client application. In such a system information is routed or streamed between the client and the server. This information includes requests from the client to invoke an object on the server and results and data from the method invocation returning from the server to the client. In addition, object-oriented programs often communicate by streaming objects from one program to another.
In such streaming operations, a stream writer organizes, or marshals, the information to form a serial data stream. The serial data stream is then sent to the server where a stream reader unmarshals, the serial data stream to reconstruct a copy of the original information. The stream reader must operate such that the unmarshaling exactly xe2x80x9cundoesxe2x80x9d the effect of the marshaling so that the original information can be reconstructed. Ordinarily, such an operation does not present a problem, but when the stream reader is not written by the same author as the stream writer there can be incompatibilities.
In order to standardize the marshaling and unmarshaling and data transfer process, an industry consortium called the Object Management Group (OMG) was formed whose mission is to define a set of interfaces for inter-operable software. Its first specification, the Common Object Request Broker Architecture (CORBA) specification, is an industry consensus standard that hides all differences between programming languages, operating systems, and object location. The CORBA standard defines an object request broker (ORB) that handles the marshaling, transport and unmarshaling of information between applications. The ORB functions as a communication infrastructure, transparently relaying object requests across distributed heterogeneous computing environments. Inter-operability is accomplished through well-defined object interface specifications which allow client applications to connect to the ORB. CORBA provides an implementation independent notation for defining interfaces called the OMG Interface Definition Language (IDL).
The OMG CORBA specification defines an implementation independent object model which is actually built with a programming language, such as C++ or Java. In this model CORBA objects (also called xe2x80x9cservantsxe2x80x9d), which are implemented by servers, have references that can be exported to clients. Clients and servers are roles, not mutually exclusive tasks for a single program, so that any one program can be both a client and a server. Objects and object references are typically different programming language objects, although they do not have to be.
In a server, the implementation of an actual object which can be used to satisfy an invocation on a CORBA object is generally both platform and language dependent and various models are possible for implementing objects in servers. The original CORBA standard defined a Basic Object Adapter (or BOA) which is a framework that adapts the server implementation to the implementation independent ORB. A newer OMG portability standard defines a Portable Object adapter (or POA), which replaces the BOA and is intended to be platform independent. Many ORBs also support other proprietary frameworks for implementing CORBA objects. All of these frameworks are commonly referred to as Object Adapters (or OAs).
One common feature shared by many OAs is that the various policies that they control may extend over collections of related objects. Illustratively, the aforementioned POA specification defines an object known as a PortableServer::POA which acts as a grouping of CORBA objects. There are many reasons for such groupings. For example, a certain group of objects may share the same mechanism for associating a servant with a CORBA object for a particular invocation. Therefore, there is a need for identifying all objects in the same grouping based on information stored in the object reference.
There may be many PortableServer::POA objects defined within a CORBA server and each of these objects has a name. These objects are also arranged in a hierarchy, with a root PortableServer::POA object defined by the POA. The names of individual POA objects are only unique within the collection of PortableServer::POA objects that share the same parent. For example, the following hierarchy defines a legal collection of PortableServer::POA objects in a CORBA server:
As illustrated, the C and D named objects are only unique within their respective A and B groups. In order to fully identify a particular PortableServer::POA object, the sequence of all names starting with the root is needed. For example, the following could be fully qualified POA names (note that the CORBA standard does not define a syntax for POA names):
Root/A/C
Root/B/C
Some data that identifies a particular instance of the PortableServer::POA class must be present in a CORBA object reference for a POA object so that the server can dispatch requests directed to the referenced object to the correct instance of the PortableServer::POA class. One method of identifying objects is to use a text string representing the name of the PortableServer::POA instance concatenated with the names of all of its ancestors. Such a string would uniquely identify each instance, but it has a variable length depending on the number of ancestors. These variable length identifiers would greatly slow the object invocation process due to the decoding time, especially when a very fast transport is used.
Therefore, it would be desirable to use a unique POA identifier which can be decoded rapidly to reduce object invocation time.
In accordance with the principles of the invention, the variable length object identifiers are translated into a fixed length compact identifier, such as a integer. The mapping for persistent objects is maintained on a server with persistent state and the mappings are ultimately written to a file.
More specifically, a new server IDL interface is defined which includes a method that accepts a fully qualified name and returns the compact identifier. The method assigns an identifier if one does not exist. Another method accepts the identifier and returns the name.
The server maintains the name-identifier mapping until it is destroyed using conventional API routines for removing servers.